NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/misc-part1/6517

Internet Message Format | 1996-08-05 | 5.1 KB

Path: surfnet.nl!sun4nl!xs4all!usenet
From: [e-mail] (Jeroen T. Vermeulen)
Newsgroups: comp.sys.amiga.misc
Subject: Re: Speed: 68040 vs. 68060
Date: Tue, 27 Feb 96 18:06:04
Organization: Leiden University, Mathematics & Computer Science, The Netherlands
Distribution: world
Message-ID: <[e-mail]>
References: <4foi00$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <4grotj$[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: asd06-24.dial.xs4all.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-NewsSoftware: GRn 2.1 Feb 19, 1994

In article <[e-mail]> [e-mail] (Mathew Hendry) writes:

> : > >BTW, running the BYTEMarks in a multitasking environment is actually likely
> : > >to show the Amiga in a good light, because AmigaOS has much lower task
> : > >switching overheads than many other multitasking OSs...
> : >
> : > Right.
> :
> : Not necessarily in this case.  What I meant is that the timing routines may
> : include time spent on other tasks.
>
> That's irrelevant. The intention is to see how long the algorithms take on a
> real system (in real time, not in CPU time). On a real system, running a real
> application, you will also have other tasks "stealing" CPU time, which
> increases the real time taken to complete a task.

On a real system, you will usually want to do several things at the same time
(even if it's just for hiding I/O latencies).  So whether or not a system is
multitasking is hardly irrelevant.  In the system we're comparing with, there
are no other tasks stealing CPU time, which increases benchmark performance, but
you won't be able to do "real" work on it either in the sense that you can on a
multitasking system.  So IMHO there is still need for caution when interpreting
these results.


> : As for task-switch overhead:  You'll note that BYTE's comparison base has *no*
> : task-switch overhead because it doesn't multitask.  It's just a plain Intel box
> : single-tasking in 32-bit mode with essentially no OS at all.
>
> Fair enough, but the base is intended as only that - a base, for comparison with
> results on other machines. Any useful OS / machine combination which you test
> will also have task switching overheads. The baseline merely serves a reference
> to put the benchmarks in a sensible range.

Not quite.  The BYTEmark figures reported for all Macs and for the PC's are for
single-tasking environments unless stated otherwise.  The figures for Amiga and
unices are not.  So IMHO the comparisons with PC's are unfair in that respect
*except* when the PC's are tested running OS/2, some UNIX, Windows NT or
(perhaps) Windows 95.


> : > >: As for FP performance, I didn't look through the source all that closely but it
> : > >: seemed to me that the FP tests happened to hammer mainly on the few FP
> : > >: instructions that aren't implemented on the 040 (and are trapped by SW
> : > >: emulation).  Here too the Amiga could be getting results that can be said to be
> : > >: artificially low by a very large factor.

...

> : Whether emulation code is inlined or not, there is a lot of overhead involved
> : simply in computing the expected results in software.  I compiled for the 040 in
> : both cases but that doesn't take away the fact that the tests may be focused on
> : an extremely unlucky part of the 040 FPU instruction set.
>
> Unlucky, maybe. But do you think that this focus is _unrepresentative_ of real
> applications?

I am simply calling attention to the possibility that the Amiga could be getting
results that _can be said to be_ artificially low (mainly depending on what kind
of code the reader is interested in).  I also *suspect* that it may be
unrepresentative of real applications, but that is my personal opinion.


> If it is representative, then you will of course be similarly unlucky in
> that applications will focus on the same instructions. People who write
> applications use the same compilers as those who compile the benchmarks, after
> all.

Seeing that Motorola's decision to not implement these instructions in
hardware anymore was partly based on their relative dynamic frequency, it is not
very likely that applications in general will "focus" on them (unless eg.
Fourier analysis has become much more common because of the hyper-hyping of
multimedia).


> If it isn't representative, then you have more of an argument.

Cut it out already!  I'm not making an argument against anybody, just pointing
out two points of caution in interpreting my results.  I'm not interested in
raising the eternal "benchmarks vs. real code" discussion here.

> -- Mat.

--
============================================================================
#  Jeroen T. Vermeulen   \"How are we doing kid?"/   Yes, we use Amigas.   #
#---  [e-mail]    ---\"Oh, same as always."/--         ...          --#
#[e-mail] \ "That bad, huh?"  /  Got a problem with that? #